home *** CD-ROM | disk | FTP | other *** search
/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / Security-HOWTO < prev    next >
Text File  |  1997-03-05  |  55KB  |  1,205 lines
  1.   Linux Security HOWTO
  2.   Kevin Fenzi, kevin@scrye.com
  3.   v0.9.5, 1 March 1998
  4.  
  5.   This document is a general overview of security issues that face the
  6.   administrator of linux systems. It covers general security philosophy
  7.   and a number of specific examples of how to better secure your linux
  8.   system from intruders. Also included are pointers to security related
  9.   material and programs. NOTE: This is a beta version of this document.
  10.   Improvements, constructive criticism,  additions and corrections are
  11.   gratefully excepted. Due to my despam filter,  you will need to mail
  12.   me to get a despam key to mail me. Sorry for the  trouble. To avoid
  13.   this make sure you have "linux", "security" or "HOWTO" in the subject
  14.   line of your mail.
  15.  
  16.   1.  Introduction
  17.  
  18.   This document covers some of the main security issues that affect
  19.   linux security. General philosophy and net born resources are
  20.   discussed.
  21.  
  22.   A number of other HOWTO documents overlap with security issues, and
  23.   those have been pointed to wherever appropriate.
  24.  
  25.   This document is NOT meant to be a up to date exploits document. Large
  26.   numbers of new exploits happen all the time. This document will tell
  27.   you where to look for such up to date information, and some general
  28.   methods to prevent such exploits from taking place.
  29.  
  30.   1.1.  New versions of this document
  31.  
  32.   New versions of this document will be periodically posted to
  33.   comp.os.linux.answers.  They will also be added to the various
  34.   anonymous FTP sites who archive such information, including:
  35.  
  36.   ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
  37.  
  38.   In addition, you should generally be able to find this document on the
  39.   Linux Worldwide Web home page via:
  40.  
  41.   http://sunsite.unc.edu/mdw/linux.html
  42.  
  43.   Finally, the very latest version of this document should also be
  44.   available in various formats from:
  45.  
  46.   http://scrye.com/~kevin/lsh/
  47.  
  48.   1.2.  Feedback
  49.  
  50.   All comments, error reports, additional information and criticism of
  51.   all sorts should be directed to:
  52.  
  53.   kevin@scrye.com
  54.  
  55.   NOTE: I use the despam filter to filter all my mail. This means that
  56.   if you are not known to me, your mail will bounce with a notice to re-
  57.   send with a provided "key" in the subject. I regret the trouble this
  58.   causes, but since I get 20-30 spam mails a day, I have to do
  59.   something. Please re-send your message with the "key" in the subject
  60.   and I will read your mail. You can also avoid this step by making sure
  61.   you put "linux" "security" or "HOWTO" in the subject of your mail.
  62.   http://scrye.com/~kevin/
  63.  
  64.   1.3.  Disclaimer
  65.  
  66.   No liability for the contents of this documents can be accepted.  Use
  67.   the concepts, examples and other content at your own risk.
  68.   Additionally, this is an early version, with many possibilities for
  69.   inaccuracies and errors.
  70.  
  71.   A number of the examples and descriptions use the RedHat(tm) package
  72.   layout and system setup. Your mileage may vary.
  73.  
  74.   As far as I know, only programs that under certain terms may be used
  75.   or evaluated for personal purposes will be described. Most of the
  76.   programs will be available complete with source under GNU-like terms.
  77.  
  78.   1.4.  Copyright information
  79.  
  80.   This document is copyrighted (c)1998 Kevin Fenzi and distributed under
  81.   the following terms:
  82.  
  83.   ╖  Linux HOWTO documents may be reproduced and distributed in whole or
  84.      in part, in any medium physical or electronic, as long as this
  85.      copyright notice is retained on all copies. Commercial
  86.      redistribution is allowed and encouraged; however, the author would
  87.      like to be notified of any such distributions.
  88.  
  89.   ╖  All translations, derivative works, or aggregate works
  90.      incorporating any Linux HOWTO documents must be covered under this
  91.      copyright notice.  That is, you may not produce a derivative work
  92.      from a HOWTO and impose additional restrictions on its
  93.      distribution. Exceptions to these rules may be granted under
  94.      certain conditions; please contact the Linux HOWTO coordinator at
  95.      the address given below.
  96.  
  97.   ╖  If you have questions, please contact Greg Hankins, the Linux HOWTO
  98.      coordinator, at
  99.  
  100.   gregh@sunsite.unc.edu Finger for phone number and snail mail address.
  101.  
  102.   2.  Overview
  103.  
  104.   This document will attempt to explain some procedures and commonly
  105.   used software to help your linux system be more secure.
  106.  
  107.   The first thing to keep in mind is that there is never any such thing
  108.   as a "completely" secure computer system. All you can do is make it
  109.   increasingly difficult for someone to compromise your system. For the
  110.   average home linux user, not much is required to keep the causal
  111.   cracker at bay. For high profile linux users (banks,
  112.   telecommunications companies, etc) much more work is required.
  113.  
  114.   Another factor to take into account is that the more you increase your
  115.   system security, the more intrusive your security becomes. You need to
  116.   decide where in this balancing act your system is still usable and yet
  117.   secure for your purposes. For instance, you could require everyone
  118.   dialing into your system to use a call back modem to call them back at
  119.   their home number. This is more secure, but if someone is not at home,
  120.   it makes it difficult for them to login. You could also setup your
  121.   linux system with no network or connection to the Internet, but this
  122.   makes it harder to surf the web. If you are a large to medium sized
  123.   site, you should establish a "Security Policy" stating how much
  124.   security is required by your site and what auditing is in place to
  125.   check it.
  126.  
  127.   This document has been segregated into several sections. They cover
  128.   several broad kinds of security issues. The first, physical security,
  129.   covers how you need to protect your physical machine from tampering.
  130.   The second describes how to protect your system from tampering by
  131.   local users. The third, network security, describes how to better
  132.   secure your linux system from network attacks. The next discusses what
  133.   to do when you detect a system compromise in progress or detect one
  134.   that has recently happened. Then links to other security resources are
  135.   enumerated, and finally a few closing words.
  136.  
  137.   The two main points to realize when reading this document are:
  138.  
  139.   ╖  Be aware of your system. Check system logs such as
  140.      /var/log/messages and keep an eye on your system, and
  141.  
  142.   ╖  Two, keep your system up to date by making sure you have installed
  143.      the current versions of software and have upgraded per security
  144.      alerts.  Just doing this will help make your system markedly more
  145.      secure.
  146.  
  147.   3.  Physical Security
  148.  
  149.   The first "layer" of security you need to take into account is the
  150.   physical security of your computer systems. Who has direct physical
  151.   access to your machine? Should they? Can you protect your machine from
  152.   their tampering? Should you?
  153.  
  154.   How much physical security you need on your system is very dependent
  155.   on your situation, and/or budget.
  156.  
  157.   If you are a home user, you probably don't need a lot (although you
  158.   might need to protect your machine from tampering by children or
  159.   annoying relatives).  If you are in a Lab environment, you need
  160.   considerably more, but users will still need to be able to get work
  161.   done on the machines. Many of the following sections will help out. If
  162.   you are in a Office, you may or may not need to secure your machine
  163.   off hours or while you are away. At some companies, leaving your
  164.   console unsecured is a termination offense.
  165.  
  166.   Obvious physical security methods such as locks on doors, cables,
  167.   locked cabinets, and video survailance are all a good idea, but beyond
  168.   the scope of this document. :)
  169.  
  170.   3.1.  Computer locks
  171.  
  172.   Many more modern pc cases include a "locking" feature. Usually this
  173.   will be a socket on the front of the case that allows you to turn an
  174.   included key to a locked or unlocked position. Case locks can help
  175.   prevent someone from stealing your pc, or opening up the case and
  176.   directly manipulating/stealing your hardware. They can also sometimes
  177.   prevent someone from rebooting your computer on their own floppy or
  178.   other hardware.
  179.  
  180.   These case locks do different things according to the support in the
  181.   motherboard and how the case is constructed. On many pc's they make it
  182.   so you have to break the case to get the case open. On some others
  183.   they make it so that it will not let you plug in new keyboards and
  184.   mice. Check your motherboard or case instructions for more
  185.   information. This can sometimes be a very useful feature, even though
  186.   the locks are usually very low quality and can easily be defeated by
  187.   attackers with locksmithing.
  188.  
  189.   Some cases (most notably sparcs and macs) have a dongle on the back
  190.   that if you put a cable through attackers would have to cut the cable
  191.   or break the case to get into it. Just putting a padlock or combo lock
  192.   through these can be a good deterrent to someone stealing your
  193.   machine.
  194.  
  195.   3.2.  BIOS Security
  196.  
  197.   The BIOS is the lowest level of software that configures or
  198.   manipulates your x86 based hardware. LILO and other linux boot methods
  199.   access the BIOS to determine how to boot up your linux machine. Other
  200.   hardware that linux runs on has similar software (OpenFirmware on macs
  201.   and new suns, sun boot prom, etc...). You can use your BIOS to prevent
  202.   attackers from rebooting your machine and manipulating your linux
  203.   system.
  204.  
  205.   Under linux/x86 many pc bioses let you set a boot password. This
  206.   doesn't provide all that much security (bios can be reset, or removed
  207.   if someone can get into the case), but might be a good deterant (ie it
  208.   will take time and leave traces of tampering).
  209.  
  210.   Many x86 bioses also allow you to specify various other good security
  211.   settings. Check your bios manual or look at it the next time you boot
  212.   up. Some examples are: disallow booting from floppy drives and
  213.   passwords to access some bios features.
  214.  
  215.   On Linux/Sparc, your SPARC eeprom can be set to require a boot-up
  216.   password. This might slow attackers down.
  217.  
  218.   NOTE: If you have a server machine, and you setup a boot password,
  219.   your machine will not boot up unattended. Keep in mind that you will
  220.   need to come in and supply the password in the even of a power
  221.   failure. ;(
  222.  
  223.   3.3.  Boot loader Security
  224.  
  225.   The various linux boot loaders also can have a boot password set.
  226.   Using lilo take a look at the "restricted" and "password" settings.
  227.   "password" allows you to set a bootup password. "restricted" will let
  228.   the machine boot _unless_ someone specifies options at the lilo:
  229.   prompt (like 'single').
  230.  
  231.   Keep in mind when setting all these passwords that you need to
  232.   remember them. :) Also remember that these passwords will mearly slow
  233.   the determined attacker.
  234.  
  235.   If anyone has security related information from a different boot
  236.   loader, I would love to hear it. (grub, silo, milo, linload, etc).
  237.  
  238.   NOTE: If you have a server machine, and you setup a boot password,
  239.   your machine will not boot up unattended. Keep in mind that you will
  240.   need to come in and supply the password in the even of a power
  241.   failure. ;(
  242.  
  243.   3.4.  xlock and vlock
  244.  
  245.   If you wander away from your machine from time to time, it is nice to
  246.   be able to "lock" your console so that no one tampers with or looks at
  247.   your work. Two programs that do this are: xlock and vlock.
  248.   Xlock is a X display locker. It should be included in any linux
  249.   distributions that support X. Check out the man page for it for more
  250.   options, but in general you can run xlock from any xterm on your
  251.   console and it will lock the display and require your password to
  252.   unlock.
  253.  
  254.   vlock is a simple little program that allows you to lock some or all
  255.   of the virtual consoles on your linux box. You can lock just the one
  256.   you are working in or all of them. If you just lock one, others can
  257.   come in and use the console, they will just not be able to use your
  258.   vty until you unlock it. vlock ships with redhat linux, but your
  259.   mileage may vary.
  260.  
  261.   Of course locking your console will prevent someone from tampering
  262.   with your work, but does not prevent them from rebooting your machine
  263.   or otherwise disrupting your work.
  264.  
  265.   3.5.  Detecting Physical Security compromises.
  266.  
  267.   The first thing to always note is when your machine was rebooted.
  268.   Since linux is a robust and stable OS, the only times your machine
  269.   should reboot is when YOU take it down for OS upgrades, hardware
  270.   swapping, or the like. If your machine has rebooted without you doing
  271.   it, a trouble light should go on. Many of the ways that your machine
  272.   can be compromised require the intruder to reboot or power off your
  273.   machine.
  274.  
  275.   Check for signs of tampering on the case and computer area. Although
  276.   many intruders clean traces of their presence out of logs, it's a good
  277.   idea to check through them all and note any discrepancy.
  278.  
  279.   Some things to check for in your logs:
  280.  
  281.   ╖  Short or incomplete logs.
  282.  
  283.   ╖  Logs containing strange timestamps.
  284.  
  285.   ╖  Logs with incorrect permissions or ownership.
  286.  
  287.   ╖  Records of reboots or restarting of services.
  288.  
  289.   ╖  missing logs.
  290.  
  291.   ╖  su entries or logins from strange places.
  292.  
  293.   Where to look for your log file will depend on your distribution. In
  294.   the standard redhat setup, you will want to look in /var/log/ and
  295.   check messages, mail.log, and others.
  296.  
  297.   You might also want to configure your log-rotating script or daemon to
  298.   keep logs around longer so you have time to examine them. Take a look
  299.   at the 'logrotate' package un recent redhat distributions. Other
  300.   distributions likely have a similar process.
  301.  
  302.   4.  Local Security
  303.  
  304.   The next thing to take a look at is the security in your system
  305.   against attacks from local users. Did I just say _local_ users? yes.
  306.  
  307.   Getting access to a local user is one of the first things that system
  308.   intruders attempt. With lax local security, they can then "upgrade"
  309.   their normal user access to root access using a variety of bugs and
  310.   poorly setup local services. If you make sure your local security is
  311.   tight, then the intruder will have another hurdle to jump.
  312.   Local users can also cause a lot of havoc with your system even
  313.   (especially) if they really are who they say they are. Providing
  314.   accounts to people you don't know or have no contact information for
  315.   is a very bad idea.
  316.  
  317.   Before changing permissions on any system files, make sure you
  318.   understand what you are doing. Never change permissions on a file
  319.   because it seems like the easy way to get things working. Always
  320.   determine why the file has that permission before changing it.
  321.  
  322.   4.1.  Creating new accounts
  323.  
  324.   You should make sure and provide user accounts with only the minimal
  325.   requirements for the task. If you provide your son (age 10) with an
  326.   account, you might want them to only have access to a word processor
  327.   or drawing program, but be unable to rm everything.
  328.  
  329.   Several good rules of thumb when allowing other people legitimate
  330.   access to your linux machine:
  331.  
  332.   ╖  Give them the minimal amount of privileges they need.
  333.  
  334.   ╖  Be aware when/where they login from, or should be logging in from.
  335.  
  336.   ╖  Make sure and remove their account when they no longer need the
  337.      access.
  338.  
  339.   Many local user accounts that are used in security compromises are
  340.   ones that have not been used in months or years. Since no one is using
  341.   them they provide the ideal attack vehicle.
  342.  
  343.   4.2.  File Permissions
  344.  
  345.   It's important to insure that your system files are not open for
  346.   casual editing by users and groups who shouldn't be doing such system
  347.   maintance.
  348.  
  349.   A quick explanation of unix permissions:
  350.  
  351.   Ownership      - Which user(s) and group(s) retain(s) control of the
  352.   permission settings of the node and parent of the node
  353.  
  354.   Permissions    - Bits capable of being set or reset to allow certain
  355.   types of access to it.
  356.  
  357.   Read:
  358.  
  359.   ╖  To be able to view contents of a file
  360.  
  361.   ╖  To be able to read a directory
  362.  
  363.   Write:
  364.  
  365.   ╖  To be able to add to or change a file
  366.  
  367.   ╖  To be able to delete or move files in a directory
  368.  
  369.   Execute:
  370.  
  371.   ╖  To be able to run a binary program
  372.  
  373.   ╖  To be able to search in a directory
  374.  
  375.   You          - The owner of the file
  376.  
  377.   Group        - The group you belong to
  378.  
  379.   Everyone     - Anyone on the system
  380.  
  381.              Examples:
  382.                -rw-r--r--  1 kevin  users         114 Aug 28  1997 .zlogin
  383.                1st bit - directory?             (no)
  384.                 2nd bit - read by owner?         (yes, by kevin)
  385.                  3rd bit - write by owner?        (yes, by kevin)
  386.                   4th bit - execute by owner?      (no)
  387.                    5th bit - read by group?         (yes, by users)
  388.                     6th bit - write by group?        (no)
  389.                      7th bit - execute by group?      (no)
  390.                       8th bit - read by everyone?      (yes, by everyone)
  391.                        9th bit - write by everyone?     (no)
  392.                         10th bit - execute by everyone?  (no)
  393.  
  394.                drwxr-xr-x  3 kevin  users         512 Sep 19 13:47 .public_html/
  395.                1st bit - directory?             (yes, it contains many files)
  396.                 2nd bit - read by owner?         (yes, by kevin)
  397.                  3rd bit - write by owner?        (yes, by kevin)
  398.                   4th bit - execute by owner?      (yes, by kevin)
  399.                    5th bit - read by group?         (yes, by users
  400.                     6th bit - write by group?        (no)
  401.                      7th bit - execute by group?      (yes, by users)
  402.                       8th bit - read by everyone?      (yes, by everyone)
  403.                        9th bit - write by everyone?     (no)
  404.                         10th bit - execute by everyone?  (yes, by everyone)
  405.  
  406.   System configuration files (usually in /etc) are usually mode 644
  407.   (-rw-r--r--), and owned by root. Depending on your sites security
  408.   requirements, you might adjust this. Never leave any system files
  409.   writable by a group or everyone.
  410.  
  411.   4.3.  Root security
  412.  
  413.   Another common local user attacker is the admin of your linux box.
  414.   yes, you! ;) Remember that you should only use the root account for
  415.   very short specific tasks and should mostly run as a normal user.
  416.   Running as root all the time is a very very very bad idea.  Just use
  417.   su or sudo to do those tasks you need to do.
  418.  
  419.   Several tricks to avoid messing up your own box as root:
  420.  
  421.   ╖  When doing some complex command, try running it first in a non
  422.      destructive way...especially commands that use globbing: ie, you
  423.      are going to do a "rm foo*.bak", instead, first do: "ls foo*.bak"
  424.      and make sure you are going to delete the files you think you are.
  425.      Using echo in place of destructive commands also sometimes works.
  426.  
  427.   ╖  Some people find it helpfull to do a "touch /-i" on their systems.
  428.      This will make commands like: "rm -rf *" ask you if you really want
  429.      to delete all the files. (It does this by your shell resolving the
  430.      "-i" file first, and treating it as the -i option to rm.) This will
  431.      not help with rm statements with no * in them. ;(
  432.  
  433.   ╖   Only become root to do single specific tasks. If you find yourself
  434.      trying to figure out how to do something, go back to a normal user
  435.      shell until you are sure what needs to be done by root.
  436.  
  437.   ╖  Always be slow and deliberate running as root. Your actions could
  438.      affect a lot of things. Think before you type!
  439.  
  440.   If you absolutely positively need to allow someone (hopefully very
  441.   trusted) to have superuser access to your machine, there are a few
  442.   tools that can help. Sudo allows users to use their password to access
  443.   a limited set of commands as root. This would allow you to, for
  444.   instance, let a user be able to eject and mount removable media on
  445.   your linux box, but have no other root privileges. sudo also keeps a
  446.   log of all sudo attempts and successes, allowing you to track down who
  447.   used what command to do what. For this reason sudo works well even in
  448.   places where a number of people have root access, but use sudo so you
  449.   can keep track of changes made.
  450.  
  451.   4.4.  Trojan Horses
  452.  
  453.   A Trojan Horse is named after the fabled ploy in Homers great literary
  454.   work. The idea is that you put up a program or binary that sounds
  455.   great, and get other people to download it and run it as root. Then,
  456.   you can compromise their system while they are not paying attention.
  457.   While they think the binary they just pulled down does one thing (and
  458.   it might very well), it also compromises their security.
  459.  
  460.   You should take care of what programs you install on your machine.
  461.   redhat provides md5 checksums and pgp signed rpm files so you can
  462.   verify you are installing the real thing. Other distributions have
  463.   similar methods. You should never run any binary you don't have the
  464.   source for or a well known binary as root! Few attackers are willing
  465.   to release source code to public scrutiny.
  466.  
  467.   Although it can be complex, make sure you are getting the source for
  468.   some program from it's real distribution site. If the program is going
  469.   to run as root make sure either you or someone you trust has looked
  470.   over the source and verified it.
  471.  
  472.   4.5.  Password Security & Encryption
  473.  
  474.   One of the most important security features used today are passwords.
  475.   It is important for both you and all your users to have secure,
  476.   unguessable passwords. Most of the more recent linux distributions
  477.   include 'passwd' programs that not allow you to set a easily guessable
  478.   password. Make sure your passwd program is up to date and has these
  479.   features.
  480.  
  481.   In depth discussion of encryption is beyond the scope of this document
  482.   , but a introduction is in order. Encryption is very usefull, possibly
  483.   even nessessary in this day and age. There are all sorts of methods of
  484.   encrypting data, each with their own flaws and drabacks. Some of the
  485.   more common ones you should be aware of:
  486.  
  487.   unix password encryption: Most unicies (and linux is no exception) use
  488.   the DES (Data Encryption Standard) to encrypt your passwords. This
  489.   encrypted password is then stored in (typically) /etc/passwd (or less
  490.   commonly) /etc/shadow. When you attempt to login, whatever you type in
  491.   is encrypted again and compaired with the entry in the passwd file. If
  492.   they match, it must be the same password and you are allowed access.
  493.   DES is a one-way encryption. DES is know to be pretty weak in these
  494.   days of fast computers. Brute force attacks, such as crack or John the
  495.   ripper (see below) can often guess passwords unless your password is
  496.   sufficently random. PAM modules (see below) allow you to use a
  497.   diffrent encryption routine with your passwords (MD5 or the like).
  498.  
  499.   4.5.1.  PAM - Pluggable Authentication Modules
  500.  
  501.   Newer versions of the RedHat linux distribution ship with a thing
  502.   called "PAM". PAM allows you to change on the fly your authentication
  503.   methods and requirements. Without re-compiling any of your binaries.
  504.   Configuration of PAM is beyond the scope of this document, take a look
  505.   at the PAM web site for more information.
  506.   http://www.kernel.org/pub/linux/libs/pam/index.html
  507.  
  508.   Just a few of the things you can do with PAM:
  509.  
  510.   ╖  Use a non DES encryption for your passwords. (Making them harder to
  511.      brute force decode.
  512.  
  513.   ╖  Set resource limits on all your users so they can't perform denial
  514.      of service attacks (number of processes, amount of memory, etc).
  515.  
  516.   ╖  Enable shadow passwords (see below) on the fly.
  517.  
  518.   ╖  allow specific users to login only at specific times from specific
  519.      places.
  520.  
  521.   4.5.2.  Shadow Passwords.
  522.  
  523.   Shadow passwords are a means of keeping your encrypted password
  524.   information secret from normal users. Normally this encrypted password
  525.   is stored in your /etc/passwd file for all to read. They can then run
  526.   password guesser programs on it and attempt to determine what it is.
  527.   Shadow passwords save this information to a /etc/shadow file that only
  528.   privileged users can read. In order to run shadow passwords you need
  529.   to make sure all your utilities that need access to password
  530.   information are recompiled to support it. PAM (above) also allows you
  531.   to just plug in a shadow module and doesn't require re-compilation of
  532.   executables.
  533.  
  534.   4.5.3.  Crack and John the Ripper
  535.  
  536.   If for some reason your passwd program is not enforcing non easily
  537.   guessable passwords, you might want to run a password cracking program
  538.   and make sure your users passwords are secure.
  539.  
  540.   Password cracking programs work on a simple idea. They try every word
  541.   in the dictionary, and then variations on those words. They encrypt
  542.   each one and check it against your encrypted password. If they get a
  543.   match they are in.
  544.  
  545.   There are a number of programs out there...the two most notable of
  546.   which are "Crack" and "John the Ripper"
  547.   http://www.false.com/security/john/index.html . They will take up a
  548.   lot of your cpu time, but you should be able to tell if an attacker
  549.   could get in using them by running them first yourself and notifying
  550.   users with weak passwords. Note that an attacker would have to use
  551.   some other hole first in order to get your passwd (unix /etc/passwd)
  552.   file, but these are more common than you might think.
  553.  
  554.   4.6.  Integrity Checking with Tripwire
  555.  
  556.   Another very good way to detect local (and also network) attacks on
  557.   your system is to run an integrity checker like Tripwire. Tripwire
  558.   runs a number of checksums on all your important binaries and config
  559.   files and compares them against a database of former values. Thus, any
  560.   changes in the files will be flagged.
  561.  
  562.   It's a good idea to install tripwire onto a floppy, and then
  563.   physically set the write protect on the floppy. This way intruders
  564.   can't tamper with tripwire itself or change the database. Once you
  565.   have tripwire setup, it's a good idea to run it once a day or so and
  566.   check to see if anything has changed.
  567.  
  568.   You can even add a crontab entry to run tripwire from your floppy
  569.   every night and mail you the results in the morning. Something like:
  570.  
  571.        # set mailto
  572.        MAILTO=kevin
  573.        # run tripwire
  574.        15 05 * * * root /usr/local/adm/tcheck/tripwire
  575.  
  576.   will mail you a report each morning at 5:15am.
  577.  
  578.   Tripwire can be a godsend to detecting intruders before you would
  579.   otherwise notice them. Since a lot of files change on the average
  580.   system, you have to be careful what is cracker activity and what is
  581.   your own doing.
  582.  
  583.   4.7.  CFS - Cryptographic File System and TCFS - transparent crypto¡
  584.   graphic File System.
  585.  
  586.   CFS is a way of encrypting an entire file system and allow users to
  587.   store encrypted files on them. It uses a NFS server running on the
  588.   local machine. rpms are avail at http://www.replay.com/redhat/ and
  589.   more information on how it all works is at:
  590.   ftp://ftp.research.att.com/dist/mab/
  591.  
  592.   TCFS improves on CFS, adding more integration with the file system, so
  593.   that it's transparent to any users using the file system that it's
  594.   encrypted. more information at: http://edu-gw.dia.unisa.it/tcfs/
  595.  
  596.   4.8.  X11, SVGA and display security.
  597.  
  598.   4.8.1.  X11
  599.  
  600.   It's important for you to secure your graphical display to prevent
  601.   attackers from doing things like: grabbing your passwords as you type
  602.   them without you knowing it, reading documents or information you are
  603.   reading on your screen, or even using a hole to gain superuser access.
  604.   Running remote X applications over a network also can be fraught with
  605.   peril, allowing sniffers to see all your interaction with the remote
  606.   system.
  607.  
  608.   X has a number of access control mechanisms. The simplest of them is
  609.   host based. You can use xhost to specify what hosts are allowed access
  610.   to your display. This is not very secure at all. If someone has access
  611.   to your machine they can xhost + their machine and get in easily.
  612.   Also, if you have to allow access from an untrusted machine, anyone
  613.   there can compromise your display.
  614.  
  615.   When using xdm (x display manager) to login, you get a much better
  616.   access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and
  617.   stored in your .Xauthorty file. If you need to allow a remote machine
  618.   access to your display, you can use the xauth command and the
  619.   information in your .Xauthority file to provide only that connection
  620.   access.
  621.  
  622.   You can also use ssh (see ssh, above) to allow secure X connections.
  623.   This has the advantage of also being transparent to the end user, and
  624.   means that no un-encrypted data flows across the network.
  625.  
  626.   Take a look at the Xsecurity man page for more information on X
  627.   security. The safe bet is to use xdm to login to your console and then
  628.   use ssh to go to remote sites you wish to run X programs off of.
  629.  
  630.   4.8.2.  SVGA
  631.  
  632.   SVGAlib programs are typically suid root in order to access all your
  633.   linux machines video hardware. This makes them very dangerous. If they
  634.   crash, you typically need to reboot your machine to get a usable
  635.   console back. Make sure any SVGA programs you are running are
  636.   authentic, and can at least be somewhat trusted. Even better, don't
  637.   run them at all.
  638.  
  639.   4.8.3.  GGI (Generic Graphics Interface project)
  640.  
  641.   The linux GGI project is trying to solve several of the problems with
  642.   video interfaces on linux. GGI will move a small piece of the video
  643.   code into the linux kernel, and then control access to the video
  644.   system. This means GGI will be able to restore your console at any
  645.   time to a known good state. They will also allow a secure attention
  646.   key, so you can be sure that there is no Trojan horse login program
  647.   running on your console. http://synergy.caltech.edu/~ggi/
  648.  
  649.   4.9.  identd
  650.  
  651.   identd is a small program that typically runs out of your inetd. It
  652.   keeps track of what user is running what tcp service, and then reports
  653.   this to whoever requests it.
  654.  
  655.   Many people misunderstand the usefulness of identd, and so disable it
  656.   or block all off site requests for it. identd is not there to help out
  657.   remote sites. There is no way of knowing if the data you get from the
  658.   remote identd is correct or not. There is no authentication in identd
  659.   requests.
  660.  
  661.   Why would you want to run it then? Because it helps _you_ out, and is
  662.   another data-point in tracking. If your identd is un compromised, then
  663.   you know it's telling remote sites the user-name or uid of people
  664.   using tcp services. If the admin at a remote site comes back to you
  665.   and tells you user so and so was trying to hack into their site, you
  666.   can easily take action against that user. If you are not running
  667.   identd, you will have to look at lots and lots of logs, figure out who
  668.   was on at the time, and in general take a lot more time to track down
  669.   the user.
  670.  
  671.   The identd that ships with most distributions is more configurable
  672.   than many people think. You can disable identd for specific users
  673.   (they can make a .noident file), you can log all identd requests (I
  674.   recommend it), you can even have identd return a uid instead of a user
  675.   name or even NO-USER.
  676.  
  677.   5.  Network Security
  678.  
  679.   Network security is becoming more and more important as people spend
  680.   more and more time connected. Compromising network security is often
  681.   much easier than physical or local, and is much more common.
  682.  
  683.   There are a number of good tools to assist with network security, and
  684.   more and more of them are shipping with linux distributions.
  685.  
  686.   5.1.  Packet Sniffers
  687.  
  688.   One of the most common ways intruders gain access to more systems on
  689.   your network is by employing a packet sniffer on a already compromised
  690.   host. This "sniffer" just listens on the Ethernet port for things like
  691.   "Password" and "Login" and "su" in the packet stream and then logs the
  692.   traffic after that. This way, attackers gain passwords for systems
  693.   they are not even attempting to break into. Clear text passwords are
  694.   very vulnerable to this attack.
  695.  
  696.   EXAMPLE: host A has been compromised. Attacker installs a sniffer.
  697.   Sniffer picks up admin logging into host B from Host C. It gets the
  698.   admins personal password as they login to B. Then, the admin does a
  699.   'su' to fix a problem. They now have the root password for Host B.
  700.   Later the admin lets someone telnet from his account to host Z on
  701.   another site. Now the attacker has a password/login on host Z.
  702.  
  703.   In this day and age, the attacker doesn't even need to compromise a
  704.   system to do this, they could also bring a laptop or pc into a
  705.   building and tap into your net.
  706.  
  707.   Using ssh or other encrypted password methods thwarts this attack.
  708.   Things like APOP for pop accounts also prevents this attack. (Normal
  709.   pop logins are very vulnerable to this, as is anything that sends
  710.   clear text passwords over the wire.)
  711.  
  712.   5.2.  System services and tcp_wrappers
  713.  
  714.   As soon as you put your linux system on ANY network the first thing to
  715.   look at is what services you need to offer. Services that you do not
  716.   need to offer should be disabled so that you have one less thing to
  717.   worry about and attackers have one less place to look for a hole.
  718.  
  719.   There are a number of ways to disable services under linux. You can
  720.   look at your /etc/inetd.conf file and see what services are being
  721.   offered by your inetd. Disable any that you do not need by commenting
  722.   them out (# at the beginning of the line), and then sending your inetd
  723.   process a SIGHUP.
  724.  
  725.   You can also remove (or comment out) services in your /etc/services
  726.   file. This will mean that local clients will also be unable to find
  727.   the service (ie, if you remove ftp, and try and ftp to a remote site
  728.   from that machine it will fail with an unknown service message). It's
  729.   usually not worth the trouble to remove services, since it provides no
  730.   additional security. If a local person wanted to use ftp even tho you
  731.   had commented it out, they would make their own client that use the
  732.   common ftp port and would still work fine.
  733.  
  734.   If you know you are not going to use some particular package, you can
  735.   also delete it entirely. rpm -e under the redhat distribution will
  736.   erase an entire package. Under debian dpkg likely does the same thing.
  737.  
  738.   You should check your /etc/rc.d/rcN.d, where N is your systems run
  739.   level and see if any of the servers started in that directory are not
  740.   needed. Simply remove the unneeded script(s) and they will not be
  741.   started on your next reboot. If you have BSD style rc files, you will
  742.   want to check /etc/rc* for programs you don't need.
  743.  
  744.   Most linux distributions ship with tcp_wrappers "wrapping" all your
  745.   tcp services. A tcp_wrapper (tcpd) is invoked from inetd instead of
  746.   the real server. tcpd then checks the host that is requesting the
  747.   service and either launches the program or denies access from that
  748.   host. tcpd allows you to restrict access to your tcp services. You
  749.   should make a /etc/hosts.allow and add in only those hosts that need
  750.   to have access to your machines services. If you are a home dialup
  751.   user, I would suggest you deny ALL. tcpd also logs failed attempts to
  752.   access services, so this can give you an idea that you are under
  753.   attack. If you add new services, you should always tcp wrapper them if
  754.   they are tcp based.
  755.  
  756.   5.3.  SATAN , ISS, and other network scanners
  757.  
  758.   There are a number of different software packages out there that do
  759.   port and service based scanning of machines or networks. SATAN and ISS
  760.   are two of the more well known ones. This software connects to the
  761.   target machine (or all the target machines on a network) on all the
  762.   ports it can, and tries to determine what service is running there.
  763.   Based on this information, you could find out the machine is
  764.   vulnerable to a specific exploit on that server.
  765.  
  766.   SATAN (Security Administrators Tool for Analyzing Networks) is a port
  767.   scanner with a web interface. It can be configured to do light,
  768.   medium, or strong checks on a machine or a network of machines. It's a
  769.   good idea to get SATAN and scan your machine or network, and fix the
  770.   problems it finds. Make sure you get the copy of SATAN from sun-site
  771.   or a reputable FTP or web site. There was a Trojan copy of SATAN that
  772.   was distributed out on the net.
  773.   http://www.trouble.org/~zen/satan/satan.html
  774.  
  775.   ISS (Internet Security Scanner) is another port based scanner. It is
  776.   faster than Satan, and thus might be better for large networks.
  777.   However, SATAN tends to provide more information.
  778.  
  779.   Detecting Port scans.
  780.  
  781.   There are some tools designed to alert you to probes by Satan and ISS
  782.   and other scanning software, However liberal use of tcp_wrappers and
  783.   making sure to look over your log files regularly, you should be able
  784.   to notice such probes. Even on the lowest setting, Satan still leaves
  785.   traces in the logs on a stock Redhat system.
  786.  
  787.   5.4.  pgp and public key cryptography
  788.  
  789.   pgp (pretty good privacy) is well supported on linux. versions 2.62
  790.   and 5.0 are known to work well. For a good primer on pgp and how to
  791.   use it, take a look a the pgp FAQ.
  792.   http://www.pgp.com/service/export/faq/55faq.cgi
  793.  
  794.   5.5.  ssh and stelnet
  795.  
  796.   ssh (secure shell) and stelnet are programs that allow you to login to
  797.   remote systems and have a encrypted connection.
  798.  
  799.   Ssh will prevent host spoofing attacks (It expects a specific key back
  800.   from a host it's connected to before), it does compression and X11
  801.   forwarding in addition to encrypting all your communications with the
  802.   remote machines. This is very good to defeat packet sniffer attacks
  803.   (The packet sniffer gets a bunch of encrypted packets). ssh is free
  804.   for personal use, so I would recommend you install it and use it if
  805.   you are at a personal site. http://www.cs.hut.fi/ssh/
  806.  
  807.   Stelnet is a secure telnet replacement that does encryption over a
  808.   telnet connection.
  809.  
  810.   5.6.  sendmail, qmail and MTA's.
  811.  
  812.   One of the most important services you can provide is a mail server.
  813.   Unfortunately, it is also one of the most vulnerable to attack, simply
  814.   due to the number of tasks it must perform and the privileges it
  815.   typically needs.
  816.  
  817.   If you are using sendmail it is very important to keep up on current
  818.   versions. Sendmail has a long long history of security exploits.
  819.   Always make sure you are running the most recent version.
  820.   http://www.sendmail.org
  821.  
  822.   If you are tired of upgrading your version of sendmail every week, you
  823.   might consider switching over to qmail. qmail was designed with
  824.   security in mind from the ground up. It's fast and stable and secure.
  825.   http://www.qmail.org
  826.  
  827.   5.7.  Denial of service attacks.
  828.  
  829.   A Denial of service attack is one where the attacker tries to make
  830.   some resource too busy to answer legitimate requests, or to deny
  831.   legitimate users access to your machine.
  832.  
  833.   Denial of service attacks have increased greatly in recent years. Some
  834.   of the more popular and recent ones are listed below. Note that new
  835.   ones show up all the time, so this is just a few examples. Read the
  836.   linux security lists for more current information.
  837.  
  838.   SYN flooding. SYN flooding is a network denial of service attack. It
  839.   takes advantage of a "loophole" in the way TCP connections are
  840.   created. The newer linux kernels (2.0.30 and up) have several
  841.   configurable options to prevent SYN flood attacks from denying people
  842.   access to your machine or services. CONFIG_SYN_COOKIES and
  843.   CONFIG_RST_COOKIES. Rebuild your kernel with these options to reduce
  844.   your susceptibility to SYN flood attacks.
  845.  
  846.   Pentium "F00F" bug. It was recently discovered that a series of
  847.   assembly codes send to a genuine Intel Pentium processor would lock
  848.   the machine up totally. This affects every machine with a Pentium
  849.   processor (not clones, not Pentium Pro or PII), no matter what
  850.   operating system it's running. Linux kernel 2.0.32 and up contain a
  851.   work around for this bug, preventing it from locking your machine. If
  852.   you are running on a pentium, you should upgrade now!
  853.  
  854.   Ping flooding. Ping flooding is a simple brute force denial of service
  855.   attack. Your attacker send a "flood" of ICMP packets to your machine.
  856.   If they are doing this from a host with better bandwidth than yours,
  857.   your machine will be unable to send anything on the network. A
  858.   variation on this attack "smurfing" sends ICMP packets to a host with
  859.   _your_ machines return IP, allowing them to flood you less detectably.
  860.   If you are under a ping flood attack, use a tool like tcpdump to
  861.   determine where the packets are coming from (or appear to be coming
  862.   from), then contact your provider with this information. Ping floods
  863.   can most easily be stopped at the router level.
  864.  
  865.   5.8.  NFS (Network File System) security.
  866.  
  867.   NFS is a very widely used file sharing protocol. It allows servers
  868.   running nfsd and mountd to "export" entire filesystems to other
  869.   machines with nfs filesystem support builtin to their kernels (or some
  870.   other client support if they are non linux machines). Mountd keeps
  871.   track of mounted filesystems in /etc/mtab, and can display them with
  872.   'showmount'.
  873.  
  874.   Many sites use NFS to serve home directories to users, so that no
  875.   matter what machine in the cluster they login to, they will have all
  876.   their home files.
  877.  
  878.   There is some small amount of "security" allowed in exporting
  879.   filesystems. You can make your nfsd map the remote root user (uid=0)
  880.   to the nobody user, denying them total access to the files exported.
  881.   However, since individual users have access to their own (or at least
  882.   the same uid) files, the remote superuser can login or su to their
  883.   account and have total access to their files. This is only a small
  884.   hindrance to an attacker that has access to mount your remote
  885.   filesystems.
  886.  
  887.   If you must use NFS, make sure you export to only those machines that
  888.   you really need to export only. Never export your entire root
  889.   directory, export only directories you need to export.
  890.  
  891.   See the NFS HOWTO for more information on NFS: NFS HOWTO
  892.  
  893.   5.9.  NIS (Network Information service) (formerly YP).
  894.  
  895.   Network Information service (formerly YP) is a means of distributing
  896.   information to a group of machines. The NIS master holds the
  897.   information tables and converts them into NIS map files. These maps
  898.   are then served over the network, allowing NIS client machines to get
  899.   login, password, home directory and shell information (all the
  900.   information in a standard /etc/passwd file). This allows users to
  901.   change their password once and have it take affect on all the machines
  902.   in the NIS domain.
  903.  
  904.   NIS is not at all secure. It was never meant to be. It was meant to be
  905.   handy and usefull. Anyone that can guess the name of your NIS domain
  906.   (anywhere on the net) can get a copy of your passwd file, and use
  907.   crack and john the ripper against your users passwords. Also, it is
  908.   possible to spoof NIS and do all sorts of nasty tricks. If you must
  909.   use NIS, make sure you are aware of the dangers.
  910.  
  911.   There is a much more secure replacement for NIS, called NIS+.  Check
  912.   out the NIS HOWTO for more information:
  913.   http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html
  914.  
  915.   5.10.  Firewalls
  916.  
  917.   Firewalls are a means of restricting what information is allowed into
  918.   and out of your local network. Typically the firewall host is
  919.   connected to the Internet and your local lan, and the only access from
  920.   your lan to the Internet is through the firewall. This way the
  921.   firewall can control what passes back and forth from the Internet and
  922.   your lan.
  923.  
  924.   There are a number of types and methods of setting up firewalls. Linux
  925.   machines make pretty good low cost firewalls. firewall code can be
  926.   built right into 2.0 and higher kernels. The ipfwadm user space tool
  927.   allows you to change what types of network traffic you allow on the
  928.   fly. You can also log particular types of network traffic.
  929.   Firewalls are a very usefull and important technique in securing your
  930.   network. It is important to realize that you should never think that
  931.   because you have a firewall, you don't need to secure the machines
  932.   behind it. This is a fatal mistake. Check out the very good Firewall-
  933.   HOWTO at your latest sun-site archive for more information on
  934.   firewalls and linux. http://sunsite.unc.edu/mdw/HOWTO/Firewall-
  935.   HOWTO.html
  936.  
  937.   6.  What to do during and after a breakin
  938.  
  939.   So you have followed some of the advice here (or elsewhere) and have
  940.   detected a breakin? The first thing to do is to remain calm. Hasty
  941.   actions can cause more harm than the attacker would have.
  942.  
  943.   6.1.  Security Compromise under way.
  944.  
  945.   Spotting a security compromise under way can be a tense undertaking.
  946.   How you react can have large consequences.
  947.  
  948.   If the compromise you are seeing is a physical one, odds are you have
  949.   spotted someone who has broken into your home, office or lab. You
  950.   should notify your local authorities. In a lab setting you might have
  951.   spotted someone trying to open a case or reboot a machine. Depending
  952.   on your authority and procedures, you might ask them to stop, or
  953.   contact your local security people.
  954.  
  955.   If you have detected a local user trying to compromise your security,
  956.   the first thing to do is confirm they are in fact who you think they
  957.   are. Check the site they are logging in from. Is it the site they are
  958.   normally in from? no? Then use a non electronic means of getting in
  959.   touch. For instance call them on the phone or walk over to their
  960.   office/house and talk to them. If they agree that they are on, you can
  961.   ask them to explain what they were doing or tell them to cease doing
  962.   it. If they are not on, and have no idea what you are talking about,
  963.   odds are this incident requires further investigation. Look into such
  964.   incidents , and have lots of information before making any
  965.   accusations.
  966.  
  967.   If you have detected a network compromise, the first thing to do (if
  968.   you are able) is to disconnect your network. If they are connected via
  969.   modem, unplug the modem cable, if they are connected via ethernet,
  970.   unplug the ethernet cable. This will prevent them from doing any
  971.   further damage, and they will probably see it as a network problem
  972.   rather than detection.
  973.  
  974.   If you are unable to disconnect the network (if you have a busy site,
  975.   or you do not have physical control of your machines), the next best
  976.   step is to use something like tcp_wrappers or ipfwadm to deny access
  977.   from the intruders site.
  978.  
  979.   If you can't deny all people from the same site as the intruder,
  980.   locking the users account will have to do. Note that locking an
  981.   account is not an easy thing. You have to keep in mind .rhosts files,
  982.   FTP access, and a host of backdoors).
  983.  
  984.   After you have done one of the above (disconnected network, denied
  985.   access from their site, and/or disabled their account), you need to
  986.   kill all their user processes and log them off.
  987.  
  988.   You should monitor your site well for the next few minutes, as the
  989.   attacker will try and get back in. Perhaps using a different account,
  990.   and/or from a different network address.
  991.  
  992.   6.2.  Security Compromise has already happened.
  993.  
  994.   So you have either detected a compromise that has already happened or
  995.   you have detected it and locked (hopefully) the offending attacker out
  996.   of your system. Now what?
  997.  
  998.   6.2.1.  Closing the Hole
  999.  
  1000.   If you are able to determine what means the attacker used to get into
  1001.   your system, you should try and close that hole. For instance, perhaps
  1002.   you see several FTP entries just before the user logged in. Disable
  1003.   the FTP service and check and see if there is an updated version or
  1004.   any of the lists know of a fix.
  1005.  
  1006.   Check all your log files, and make a visit to your security lists and
  1007.   pages and see if there are any new common exploits you can fix.
  1008.  
  1009.   If you don't lock the attacker out, they will likely be back. Not just
  1010.   back on your machine, but back somewhere on your lan. If they were
  1011.   running a packet sniffer, odds are good they have access to other
  1012.   local machines.
  1013.  
  1014.   6.2.2.  Assessing the Damage
  1015.  
  1016.   The first thing is to assess the damage. What has been compromised?
  1017.   If you are running an Integrity Checker like Tripwire you can make a
  1018.   tripwire run and it should tell you. If not, you will have to look
  1019.   around at all your important data.
  1020.  
  1021.   Since linux systems are getting easier and easier to install, you
  1022.   might consider saving off your config files and then wiping your
  1023.   disk(s) and reinstalling, then restoring your user files from backups
  1024.   and your config files. This will insure that you have a new clean
  1025.   system.
  1026.  
  1027.   6.2.3.  Backups, Backups, Backups!
  1028.  
  1029.   Having regular backups is a godsend for security matters. If your
  1030.   system is compromised, you can restore the data you need from backups.
  1031.   Of course some data is valuable to the attacker to, and they will not
  1032.   only destroy it, they will steal it and have their own copies, but at
  1033.   least you will still have the data.
  1034.  
  1035.   You should check several backups back into the past before restoring a
  1036.   file that has been tampered with. The intruder could have compromised
  1037.   your files long ago, and you could have made many successful backups
  1038.   of the compromised file!!!
  1039.  
  1040.   Of course, there are also a raft of security concerns with backups.
  1041.   Make sure you are storing them in a secure place. Know who has access
  1042.   to them. (If an attacker can get your backups, they can have access to
  1043.   all your data without you ever knowing it.)
  1044.  
  1045.   6.2.4.  Tracking down the intruder.
  1046.  
  1047.   Ok, you have locked the intruder out, and recovered your system, but
  1048.   you're not quite done yet. While it is unlikely that most intruders
  1049.   will ever be caught, you should report the attack.
  1050.  
  1051.   You should report the attack to the admin contact at the site where
  1052.   the attacker attacked your system. You can look up this contact with
  1053.   "whois" or the internic database. You might send them an email with
  1054.   all applicable log entries and dates and times. If you spotted
  1055.   anything else distinctive about your intruder, you might mention that
  1056.   too. After sending the email, you should (if you are so inclined)
  1057.   follow up with a phone call. If that admin in turn spots your
  1058.   attacker, they might be able to talk to the admin of the site where
  1059.   they are coming from and so on.
  1060.  
  1061.   Good hackers often use many intermediate systems. Some (or many) of
  1062.   which may not even know they have been compromised. Trying to track a
  1063.   cracker back to their home system can be difficult. Being polite to
  1064.   the admins you talk to can go a long way to getting help from them.
  1065.  
  1066.   You should also notify any security organizations you are a part of
  1067.   (cert or similar).
  1068.  
  1069.   7.  Security sources
  1070.  
  1071.   There are a LOT of good sites out there for unix security in general
  1072.   and linux security specifically. It's very important to subscribe to
  1073.   one (or more) of the security mailing lists and keep current on
  1074.   security fixes. Most of these lists are very low volume, and very
  1075.   informative.
  1076.  
  1077.   7.1.  FTP sites
  1078.  
  1079.   CERT is the Computer Emergency Response Team. They often send out
  1080.   alerts of current attacks and fixes. cert.org
  1081.  
  1082.   Replay has archives of many security programs. Since they are outside
  1083.   the US, they don't need to obey any silly US crypto restrictions.
  1084.   replay.com
  1085.  
  1086.   Matt Blaze is the author of CFS and a great security advocate.  Matt
  1087.   Blaze's stuff
  1088.  
  1089.   Sorosis is the home of the linux PAM site. They have lots of modules
  1090.   and information on PAM.  Linux PAM ftp site
  1091.  
  1092.   tue.nl is a great security ftp site in the Netherlands.
  1093.   ftp.win.tue.nl
  1094.  
  1095.   7.2.  The Hacker FAQ is a FAQ about hackers: The Hacker FAQ web sites
  1096.  
  1097.   The COAST archive has a large number of unix security programs and
  1098.   information: COAST
  1099.  
  1100.   Rootshell.com is a great site for seeing what exploits are currently
  1101.   being used by crackers: rootshell.com exploits
  1102.  
  1103.   BUGTRAQ puts out advisories on security issues: BUGTRAQ archives
  1104.  
  1105.   CERT, the Computer Emergency Response Team, puts out advisories on
  1106.   common attacks on unix platforms: CERT home
  1107.  
  1108.   Dan Farmer is the author of SATAN and many other security tools, his
  1109.   home site has some interesting security survey information as well as
  1110.   security tools: Dan Farmers trouble.org
  1111.  
  1112.   The linux security WWW is a good site for linux security information:
  1113.   Linux Security WWW
  1114.  
  1115.   Reptile has lots of good linux security information on his site:
  1116.   Reptiles Linux Security Page
  1117.  
  1118.   Infilsec has a vulnerability engine that can tell you what
  1119.   vunerabilities affect a specific platform: Infilsec vunerability
  1120.   engine
  1121.  
  1122.   CIAC sends out periodic security bulitins on common exploits: CIAC
  1123.   bulitins
  1124.  
  1125.   7.3.  mailing lists
  1126.  
  1127.   Bugtraq:  To subscribe to bugtraq, send mail to listserv@netspace.org
  1128.   containing the message body subscribe bugtraq. (see links above for
  1129.   archives).
  1130.  
  1131.   CIAC: Send e-mail to: majordomo@tholia.llnl.gov In the BODY (not
  1132.   subject) of the message put (either or both): subscribe ciac-bulletin
  1133.  
  1134.   7.4.  Books - printed reading material.
  1135.  
  1136.   There are a number of good security books out there. This section
  1137.   lists a few of them. In addition to the security specify books,
  1138.   security is covered in a number of other books on system
  1139.   administration.
  1140.  
  1141.   Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky
  1142.  
  1143.   1st Edition September 1995
  1144.  
  1145.   ISBN: 1-56592-124-0
  1146.  
  1147.   Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel &
  1148.   Gene Spafford
  1149.  
  1150.   2nd Edition April 1996
  1151.  
  1152.   ISBN: 1-56592-148-8
  1153.  
  1154.   Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr.
  1155.  
  1156.   1st Edition July 1991
  1157.  
  1158.   ISBN: 0-937175-71-4
  1159.  
  1160.   Linux Network Administrator's Guide By Olaf Kirch
  1161.  
  1162.   1st Edition January 1995
  1163.  
  1164.   ISBN: 1-56592-087-2
  1165.  
  1166.   PGP: Pretty Good Privacy By Simson Garfinkel
  1167.  
  1168.   1st Edition December 1994
  1169.  
  1170.   ISBN: 1-56592-098-8
  1171.  
  1172.   Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger &
  1173.   William VonStorch (Consulting Editor Eugene H. Spafford)
  1174.  
  1175.   1st Edition August 1995
  1176.  
  1177.   ISBN: 1-56592-086-4
  1178.  
  1179.   8.  Conclusion
  1180.  
  1181.   By subscribing to the security alert mailing lists, and keeping
  1182.   current, you can do a lot towards securing your machine. If you pay
  1183.   attention to your log files and run something like tripwire regularly,
  1184.   you can do even more.
  1185.  
  1186.   A reasonable level of computer security is not difficult to maintain
  1187.   on a home machine. More effort is required on business machines, but
  1188.   linux can indeed be a secure platform. Due to the nature of linux
  1189.   development, security fixes often come out much faster than they do on
  1190.   commercial operating systems, making linux an ideal platform when
  1191.   security is a requirement.
  1192.  
  1193.   9.  Thanks to
  1194.  
  1195.   Information here is collected from many sources. Thanks to the
  1196.   following that either indirectly or directly have contributed:
  1197.  
  1198.        Rob Riggs <rob@DevilsThumb.com>
  1199.        S. Coffin <scoffin@netcom.com>
  1200.        Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu>
  1201.        Roelof Osinga <roelof@eboa.com>
  1202.        Kyle Hasselbacher <kyle@carefree.quux.soltec.net>
  1203.        "David S. Jackson" <dsj@dsj.net>
  1204.  
  1205.